In the Linux kernel, the following vulnerability has been resolved:

net: airoha: Fix use-after-free in metadata dst teardown

airohametadatadstfree() runs metadatadstfree() which frees the metadatadst with kfree() immediately, bypassing the RCU grace period. In the RX path, skbdstsetnoref() sets a non-refcounted pointer from the skb to the metadatadst. This function requires RCU read-side protection and the dst must remain valid until all RCU readers complete. Since metadatadstfree() calls kfree() directly, an use-after-free can occur if any skb still holds a noref pointer to the dst when the driver tears it down. Replace metadatadstfree() with dstrelease() which properly goes through the refcount path: when the refcount drops to zero, it schedules the actual free via callrcuhurry(), ensuring all RCU readers have completed before the memory is freed.

In the Linux kernel, the following vulnerability has been resolved:

net/mlx5: Fix slab-out-of-bounds in mlx5querynicvportmaclist

mlx5querynicvportmaclist() sizes its firmware command buffer using the PF's logmaxcurrentuc/mclist capabilities. When querying a VF vport with a larger configured max (via devlink), the firmware response can overflow this buffer:

BUG: KASAN: slab-out-of-bounds in mlx5querynicvportmaclist+0x453/0x4c0 [mlx5core] Read of size 4 at addr ff1100013ffc8a12 by task kworker/u96:2/385

CPU: 12 UID: 0 PID: 385 Comm: kworker/u96:2 Not tainted 7.0.0-rc6+ #1 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) Workqueue: mlx5eswwq eswvportchangehandler [mlx5core] Call Trace: <TASK> dumpstacklvl+0x69/0xa0 printreport+0x176/0x4e4 kasanreport+0xc8/0x100 mlx5querynicvportmaclist+0x453/0x4c0 [mlx5core] eswupdatevportaddrlist+0x2e3/0xda0 [mlx5core] eswvportchangehandlelocked+0xa1f/0x1060 [mlx5core] eswvportchangehandler+0x6a/0x90 [mlx5core] processonework+0x87f/0x15e0 workerthread+0x62b/0x1020 kthread+0x375/0x490 retfromfork+0x4dc/0x810 retfromforkasm+0x11/0x20 </TASK>

Fix by querying the vport's own HCA caps to size the buffer correctly. Refactor the function to allocate and return the MAC list internally, removing the caller's dependency on knowing the correct max.

dm cache: fix dirty mapping checking in passthrough mode switching

In the Linux kernel, the following vulnerability has been resolved:

iommu/riscv: Add IOTINVAL after updating DDT/PDT entries

Add riscviommuiodiriotinval() to perform required TLB and context cache invalidations after updating DDT or PDT entries, as mandated by the RISC-V IOMMU specification (Section 6.3.1 and 6.3.2).

In the Linux kernel, the following vulnerability has been resolved:

scsi: target: core: Fix integer overflow in UNMAP bounds check

sbcexecuteunmap() checks LBA + range does not exceed the device capacity, but does not guard against LBA + range wrapping around on 64-bit overflow.

Add an overflow check matching the pattern already used for WRITESAME in the same file.

In the Linux kernel, the following vulnerability has been resolved:

pppoe: drop PFC frames

RFC 2516 Section 7 states that Protocol Field Compression (PFC) is NOT RECOMMENDED for PPPoE. In practice, pppd does not support negotiating PFC for PPPoE sessions, and the current PPPoE driver assumes an uncompressed (2-byte) protocol field. However, the generic PPP layer function pppinput() is not aware of the negotiation result, and still accepts PFC frames.

If a peer with a broken implementation or an attacker sends a frame with a compressed (1-byte) protocol field, the subsequent PPP payload is shifted by one byte. This causes the network header to be 4-byte misaligned, which may trigger unaligned access exceptions on some architectures.

To reduce the attack surface, drop PPPoE PFC frames. Introduce pppskbiscompressedproto() helper function to be used in both pppgeneric.c and pppoe.c to avoid open-coding.

In the Linux kernel, the following vulnerability has been resolved:

net/sched: netem: fix queue limit check to include reordered packets

The queue limit check in netemenqueue() uses q->tlen which only counts packets in the internal tfifo. Packets placed in sch->q by the reorder path (qdiscenqueuehead) are not counted, allowing the total queue occupancy to exceed sch->limit under reordering.

Include sch->q.qlen in the limit check.

In the Linux kernel, the following vulnerability has been resolved:

ipc/shm: serialize orphan cleanup with shmnattch updates

shmdestroyorphaned() walks the shm idr under shmids(ns).rwsem, but that does not serialize all fields tested by shmmaydestroy(). In particular, shmnattch is updated while holding shmperm.lock, and attach paths can do that without holding the rwsem.

Do not decide that an orphaned segment is unused before taking the object lock. Move the shmmaydestroy() check under shmperm.lock, matching the other destroy paths, and unlock the segment when it no longer qualifies for removal.

In the Linux kernel, the following vulnerability has been resolved:

nfc: hci: shdlc: Stop timers and work before freeing context

llcshdlcdeinit() purges SHDLC skb queues and frees the llcshdlc structure while its timers and state machine work may still be active.

Timer callbacks can schedule smwork, and smwork accesses SHDLC state and the skb queues. If teardown happens in parallel with a queued/running work item, it can lead to UAF and other shutdown races.

Stop all SHDLC timers and cancel smwork synchronously before purging the queues and freeing the context.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

batman-adv: stop caching unowned originator pointers in BAT IV

drm/amdgpu/sdma4: replace BUGON with WARNON in fence emission

In the Linux kernel, the following vulnerability has been resolved:

smb: client: validate dacloffset before building DACL pointers

parsesecdesc(), buildsecdesc(), and the chown path in idmodetocifsacl() all add the server-supplied dacloffset to pntsd before proving a DACL header fits inside the returned security descriptor.

On 32-bit builds a malicious server can return dacloffset near U32MAX, wrap the derived DACL pointer below endofacl, and then slip past the later pointer-based bounds checks. buildsecdesc() and idmodetocifsacl() can then dereference DACL fields from the wrapped pointer in the chmod/chown rewrite paths.

Validate dacloffset numerically before building any DACL pointer and reuse the same helper at the three DACL entry points.

In the Linux kernel, the following vulnerability has been resolved:

RDMA/mlx5: Fix error path fall-through in mlx5ibdevressrqinit()

mlx5ibdevressrqinit() allocates two SRQs, s0 and s1. When ibcreatesrq() fails for s1, the error branch destroys s0 but falls through and unconditionally assigns the freed s0 and the ERRPTR s1 to devr->s0 and devr->s1.

This leads to several problems: the lock-free fast path checks "if (devr->s1) return 0;" and treats the ERRPTR as already initialised; users in mlx5ibcreateqp() dereference the freed SRQ or ERRPTR via tomsrq(devr->s0)->msrq.srqn; and mlx5ibdevrescleanup() dereferences the ERRPTR and double-frees s0 on teardown.

Fix by adding the same goto unlock in the s1 failure path.

In the Linux kernel, the following vulnerability has been resolved:

wifi: mt76: mt7921: fix a potential clc buffer length underflow

The buflen is used to limit the iterations for retrieving the country power setting and may underflow under certain conditions due to changes in the power table in CLC.

This underflow leads to an almost infinite loop or an invalid power setting resulting in driver initialization failure.

In the Linux kernel, the following vulnerability has been resolved:

RDMA/hns: Fix unlocked call to hnsroceqpremove()

Sashiko points out that hnsroceqpremove() requires the caller to hold locks. The error flow in hnsrocecreateqpcommon() doesn't hold those locks for the error unwind so it risks corrupting memory.

Grab the same locks the other two callers use.

In the Linux kernel, the following vulnerability has been resolved:

usb: ulpi: fix memory leak on ulpiregister() error paths

Commit 01af542392b5 ("usb: ulpi: fix double free in ulpiregisterinterface() error path") removed kfree(ulpi) from ulpiregisterinterface() to fix a double-free when deviceregister() fails.

But when ulpiofregister() or ulpireadid() fail before deviceregister() is called, the ulpi allocation is leaked.

Add kfree(ulpi) on both error paths to properly clean up the allocation.

In the Linux kernel, the following vulnerability has been resolved:

ipmi:si: Return state to normal if message allocation fails

There were places where nothing would get started if a message allocation failed, so the driver needs to return to normal state.

In the Linux kernel, the following vulnerability has been resolved:

selinux: use sk blob accessor in socket permission helpers

SELinux socket state lives in the composite LSM socket blob.

sockhasperm() and nlmsgsockhasextendedperms() currently dereference sk->sksecurity directly, which assumes the SELinux socket blob is at offset zero.

In stacked configurations that assumption does not hold. If another LSM allocates socket blob storage before SELinux, these helpers may read the wrong blob and feed invalid SID and class values into AVC checks.

Use selinuxsock() instead of accessing sk->sksecurity directly.

In the Linux kernel, the following vulnerability has been resolved:

gfs2: Fix use-after-free in iomap inline data write path

The inline data buffer head (dibh) is being released prematurely in gfs2iomapbegin() via releasemetapath() while iomap->inlinedata still points to dibh->bdata. This causes a use-after-free when iomapwriteendinline() later attempts to write to the inline data area.

The bug sequence: 1. gfs2iomapbegin() calls gfs2metainodebuffer() to read inode metadata into dibh 2. Sets iomap->inlinedata = dibh->bdata + sizeof(struct gfs2dinode) 3. Calls releasemetapath() which calls brelse(dibh), dropping refcount to 0 4. kswapd reclaims the page (~39ms later in the syzbot report) 5. iomapwriteendinline() tries to memcpy() to iomap->inlinedata 6. KASAN detects use-after-free write to freed memory

Fix by storing dibh in iomap->private and incrementing its refcount with getbh() in gfs2iomapbegin(). The buffer is then properly released in gfs2iomapend() after the inline write completes, ensuring the page stays alive for the entire iomap operation.

Note: A C reproducer is not available for this issue. The fix is based on analysis of the KASAN report and code review showing the buffer head is freed before use.

[agruenba: Take buffer head reference in gfs2iomapbegin() to avoid leaks in gfs2iomapget() and gfs2iomapalloc().]

In the Linux kernel, the following vulnerability has been resolved:

spi: ch341: fix memory leaks on probe failures

Make sure to deregister the controller, disable pins, and kill and free the RX URB on probe failures to mirror disconnect and avoid memory leaks and use-after-free.

Also add an explicit URB kill on disconnect for symmetry (even if that is not strictly required as USB core would have stopped it in the current setup).

In the Linux kernel, the following vulnerability has been resolved:

RDMA/rxe: Validate pad and ICRC before payloadsize() in rxercv

rxercv() currently checks only that the incoming packet is at least headersize(pkt) bytes long before payloadsize() is used.

However, payloadsize() subtracts both the attacker-controlled BTH pad field and RXEICRCSIZE from pkt->paylen:

payloadsize = pkt->paylen - offset[RXEPAYLOAD] - bthpad(pkt) - RXEICRCSIZE

This means a short packet can still make payloadsize() underflow even if it includes enough bytes for the fixed headers. Simply requiring headersize(pkt) + RXEICRCSIZE is not sufficient either, because a packet with a forged non-zero BTH pad can still leave payloadsize() negative and pass an underflowed value to later receive-path users.

Fix this by validating pkt->paylen against the full minimum length required by payloadsize(): headersize(pkt) + bthpad(pkt) + RXEICRCSIZE.

In the Linux kernel, the following vulnerability has been resolved:

hwmon: (pt5161l) Fix bugs in pt5161lreadblockdata()

Fix two bugs in pt5161lreadblockdata():

1. Buffer overrun: The local buffer rbuf is declared as u8 rbuf[24], but i2csmbusreadblockdata() can return up to I2CSMBUSBLOCKMAX (32) bytes. The i2c-core copies the data into the caller's buffer before the return value can be checked, so the post-read length validation does not prevent a stack overrun if a device returns more than 24 bytes. Resize the buffer to I2CSMBUSBLOCKMAX.

2. Unexpected positive return on length mismatch: When all three retries are exhausted because the device returns data with an unexpected length, i2csmbusreadblockdata() returns a positive byte count. The function returns this directly, and callers treat any non-negative return as success, processing stale or incomplete buffer contents. Return -EIO when retries are exhausted with a positive return value, preserving the negative error code on I2C failure.

In the Linux kernel, the following vulnerability has been resolved:

HID: playstation: Add missing check for inputffcreatememless

The psgamepadcreate() function calls inputffcreatememless() without verifying its return value, which can lead to incorrect behavior or potential crashes when FF effects are triggered.

Add a check for the return value of inputffcreatememless().

In the Linux kernel, the following vulnerability has been resolved:

drm/exynos: vidi: use priv->vididev for ctx lookup in vidiconnectionioctl()

vidiconnectionioctl() retrieves the driverdata from drmdev->dev to obtain a struct vidicontext pointer. However, drmdev->dev is the exynos-drm master device, and the driverdata contained therein is not the vidi component device, but a completely different device.

This can lead to various bugs, ranging from null pointer dereferences and garbage value accesses to, in unlucky cases, out-of-bounds errors, use-after-free errors, and more.

To resolve this issue, we need to store/delete the vidi device pointer in exynosdrmprivate->vididev during bind/unbind, and then read this exynosdrmprivate->vididev within ioctl() to obtain the correct struct vidicontext pointer.

In the Linux kernel, the following vulnerability has been resolved:

fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot

In the 'DeleteIndexEntryRoot' case of the 'doaction' function, the entry size ('esize') is retrieved from the log record without adequate bounds checking.

Specifically, the code calculates the end of the entry ('e2') using: e2 = Add2Ptr(e1, esize);

It then calculates the size for memmove using 'PtrOffset(e2, ...)', which subtracts the end pointer from the buffer limit. If 'esize' is maliciously large, 'e2' exceeds the used buffer size. This results in a negative offset which, when cast to sizet for memmove, interprets as a massive unsigned integer, leading to a heap buffer overflow.

This commit adds a check to ensure that the entry size ('esize') strictly fits within the remaining used space of the index header before performing memory operations.

In the Linux kernel, the following vulnerability has been resolved:

serial: caif: fix use-after-free in caifserial ldiscclose()

There is a use-after-free bug in caifserial where handletx() may access ser->tty after the tty has been freed.

The race condition occurs between ldiscclose() and packet transmission:

CPU 0 (close) CPU 1 (xmit) ------------- ------------ ldiscclose() ttykrefput(ser->tty) [tty may be freed here] <-- race window --> caifxmit() handletx() tty = ser->tty // dangling ptr tty->ops->write() // UAF! schedulework() serrelease() unregisternetdevice()

The root cause is that ttykrefput() is called in ldiscclose() while the network device is still active and can receive packets.

Since ser and tty have a 1:1 binding relationship with consistent lifecycles (ser is allocated in ldiscopen and freed in serrelease via unregisternetdevice, and each ser binds exactly one tty), we can safely defer the tty reference release to serrelease() where the network device is unregistered.

Fix this by moving ttykrefput() from ldiscclose() to serrelease(), after unregisternetdevice(). This ensures the tty reference is held as long as the network device exists, preventing the UAF.

Note: We save ser->tty before unregisternetdevice() because ser is embedded in netdev's private data and will be freed along with netdev (needsfreenetdev = true).

How to reproduce: Add mdelay(500) at the beginning of ldiscclose() to widen the race window, then run the reproducer program [1].

Note: There is a separate deadloop issue in handletx() when using PORTUNKNOWN serial ports (e.g., /dev/ttyS3 in QEMU without proper serial backend). This deadloop exists even without this patch, and is likely caused by inconsistency between uartwriteroom() and uartwrite() in serial core. It has been addressed in a separate patch [2].

KASAN report:

================================================================== BUG: KASAN: slab-use-after-free in handletx+0x5d1/0x620 Read of size 1 at addr ffff8881131e1490 by task caifuaftrigge/9929

Call Trace: <TASK> dumpstacklvl+0x10e/0x1f0 printreport+0xd0/0x630 kasanreport+0xe4/0x120 handletx+0x5d1/0x620 devhardstartxmit+0x9d/0x6c0 devqueuexmit+0x6e2/0x4410 packetxmit+0x243/0x360 packetsendmsg+0x26cf/0x5500 syssendto+0x4a3/0x520 x64syssendto+0xe0/0x1c0 dosyscall64+0xc9/0xf80 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f615df2c0d7

Allocated by task 9930:

Freed by task 64:

Last potentially related work creation:

The buggy address belongs to the object at ffff8881131e1000 which belongs to the cache kmalloc-cg-2k of size 2048 The buggy address is located 1168 bytes inside of freed 2048-byte region [ffff8881131e1000, ffff8881131e1800)

The buggy address belongs to the physical page: pageowner tracks the page as allocated page last free pid 9778 tgid 9778 stack trace:

Memory state around the buggy address: ffff8881131e1380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8881131e1400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8881131e1480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8881131e1500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8881131e1580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== [1]: https://gist.github.com/mrpre/f683f244544f7b11e7fa87df9e6c2eeb [2]: https://lore.kernel.org/linux-serial/20260204074327.226165-1-jiayuan.chen@linux.dev/T/#u

In the Linux kernel, the following vulnerability has been resolved:

crypto: inside-secure/eip93 - unregister only available algorithm

EIP93 has an options register. This register indicates which crypto algorithms are implemented in silicon. Supported algorithms are registered on this basis. Unregister algorithms on the same basis. Currently, all algorithms are unregistered, even those not supported by HW. This results in panic on platforms that don't have all options implemented in silicon.

In the Linux kernel, the following vulnerability has been resolved:

apparmor: fix NULL sock in aasockfileperm

Deal with the potential that sock and sock-sk can be NULL during socket setup or teardown. This could lead to an oops. The fix for NULL pointer dereference in unixneedsrevalidation shows this is at least possible for afunix sockets. While the fix for afunix sockets applies for newer mediation this is still the fall back path for older afunix mediation and other sockets, so ensure it is covered.

In the Linux kernel, the following vulnerability has been resolved:

drm/panthor: Fix NULL pointer dereference on panthorfwunplug

This patch removes the MCU halt and wait for halt procedures during panthorfwunplug() as the MCU can be in a variety of states or the FW may not even be loaded/initialized at all, the latter of which can lead to a NULL pointer dereference.

It should be safe on unplug to just disable the MCU without waiting for it to halt as it may not be able to.

Hi Salvatore, all,

On Fri, May 15, 2026 at 07:12:08AM +0200, Salvatore Bonaccorso wrote: I'm not 100% certain, but setting restrictive kernel.yama.ptracescope might as well serve as temporary workaround. Can you confirm? Excellent question, thank you very much! We have just now tried, and setting /proc/sys/kernel/yama/ptracescope to 2 (admin-only attach) or 3 (no attach) does in fact protect against all the exploits that we know of (but in theory at least other exploitation methods might exist).

Thanks again! With best regards,

-- the Qualys Security Advisory team